Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: add a helper method to create a dedicated virtual thread scheduler. #164

Merged
merged 1 commit into from
Feb 2, 2025

Conversation

He-Pin
Copy link
Contributor

@He-Pin He-Pin commented Jan 21, 2025

Motivation:
Add a helper method to create a separate virtual thread scheduler.

maximumPoolSize: Int,
keepAliveTime: Int,
timeUnit: TimeUnit): ForkJoinPool = {
new ForkJoinPool(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it need to be a ForkJoinPool, or can other pools work? I've had odd interactions between ForkJoinPool and other libraries (e.g. scala.util.concurrent.blocking) so I wonder if we can provide alternative pools

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it can be any Executor, just make sure a virtual thread can be always run. We can use Executor#newCachedThreadPool, or ThreadPoolExecutor with a larger max pool size (because of the classloading issue) if we have a small thread pool size, and then the Virtual thread may not be able to run, then deadlock can happen, I have updated the method name.

This help method is just integrated with the CarrierThreadFactory.

see: https://openjdk.org/jeps/491

Future Work
There are a few remaining cases, unrelated to the synchronized keyword, in which a virtual thread cannot unmount when blocking:

When resolving a symbolic reference ([JVMS §5.4.3](https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-5.html#jvms-5.4.3)) to a class or interface and the virtual thread blocks while loading a class. This is a case where the virtual thread pins the carrier due to a native frame on the stack.

When blocking inside a class initializer. This is also a case where the virtual thread pins the carrier due to a native frame on the stack.

When waiting for a class to be initialized by another thread ([JVMS §5.5](https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-5.html#jvms-5.5)). This is a special case where the virtual thread blocks in the JVM, thus pinning the carrier.

These cases should rarely cause issues but we will revisit them if they prove to be problematic.

@lihaoyi lihaoyi merged commit b27a63e into com-lihaoyi:master Feb 2, 2025
8 of 9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants